Android Handler的理解

​ Handler是Android给我们提供用来更新UI的一套机制,是一套消息处理机制,可以通过它来发送消息和处理消息。那作为开发者的我们,不禁会疑问?Google为什么要设计这套机制呢?这是为了解决在非UI线程中更新UI组件比较麻烦的问题。那么Android为什么不能在非UI线程中更新呢?首先Android的UI控件不是线程安全的,这是因为避免多线程并发所带来不安全问题。例如作一个假设,现在在子线程中刷新界面,同时也在UI线程中刷新界面,就会出现刷新不同步,简单来讲通过Handler就可以将更新UI操作切换到主线程中执行。

1、Handler的使用

​ 日常中我们使用Handler的场景可能大多是在子线程中进行了耗时操作,比如网络请求数据,拿到数据后我们可能会更新UI控件,因为Android规定只能在主线程进行UI操作,这时候我们通常会在主线程中创建一个Handler,然后通过在子线程中使用Handler发送消息发送到主线程,然后在主线程中消息回调的handleMessage()中处理我们的消息,示例一如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

public class MainActivity extends AppCompatActivity {

private Button mBtnTest;
private Handler mTestHandler = new Handler(){
@Override
public void handleMessage(Message msg) {
switch (msg.what){
case 1:
mBtnTest.setText("收到消息");
}
}
};
@Override
protected void onCreate(final Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mBtnTest = (Button) findViewById(R.id.btn_test);
new Thread(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(3000);
mTestHandler.sendEmptyMessage(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}).start();
}
}

除此之外,还有一种常见的用法,示例二如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
public class MainActivity extends AppCompatActivity {

private Button mBtnTest;
private Handler mTestHandler = new Handler();


@Override
protected void onCreate(final Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mBtnTest = findViewById(R.id.btn_test);
new Thread(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
}

mTestHandler.post(new Runnable() {
@Override
public void run() {
mBtnTest.setText("收到消息");
}
});
}
}).start();
}
}

2、Handler的原理

​ 在了解了Handler的用法之后,我们就需要思考一个问题,为什么Handler可以做到将UI操作从子线程切换到UI线程来执行呢,在这个过程中经历了什么?

​ 从上面的示例代码中可以看到消息最终还是会回到Handler手上,由他自己处理。那么我们搞清楚的就是这个消息由发到收的过程。

2.1、Message的发送

首先,来看一下示例一中的消息发送:

mTestHandler.sendEmptyMessage(1);

然后,我们追随sendEmptyMessage()方法下去,得到一个结论:Handler无论以何种方式发送何种消息,都会经过到sendMessageAtTime()方法:

1
2
3
4
5
6
7
8
9
10
public boolean sendMessageAtTime(Message msg, long uptimeMillis) {
MessageQueue queue = mQueue;
if (queue == null) {
RuntimeException e = new RuntimeException(
this + " sendMessageAtTime() called with no mQueue");
Log.w("Looper", e.getMessage(), e);
return false;
}
return enqueueMessage(queue, msg, uptimeMillis);
}

而此方法会先判断当前Handler的mQueue对象是否为空,再调用enqueueMessage()方法,从字面意思不难理解是将该消息入队保存起来。再看enqueueMessage()方法:

1
2
3
4
5
6
7
8
9
10
11
12
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
msg.target = this;
if (mAsynchronous) {
msg.setAsynchronous(true);
}
return queue.enqueueMessage(msg, uptimeMillis);
}

public final class Message implements Parcelable {
//....
Handler target;
}

该方法会先将Message和当前Handler绑定起来,不难理解当需要处理Message时直接甩给绑定他的Handler就是了。再调用queue.enqueueMessage()方法正式入队,而queue对象到底是一个什么样的对象?由单向链表实现的消息队列。queue.enqueueMessage()方法就是遍历链表将消息插入表尾保存起来,而从queue取消息就是把表头的Message拿出来。

接着来要搞清楚的是queue是何时怎样创建的?来看Handler的构造函数。

1
2
3
4
5
6
7
8
9
10
public Handler(Callback callback, boolean async) {
mLooper = Looper.myLooper();
if (mLooper == null) {
throw new RuntimeException(
"Can't create handler inside thread that has not called Looper.prepare()");
}
mQueue = mLooper.mQueue;
mCallback = callback;
mAsynchronous = async;
}

Handler的构造方法会先调用Looper.myLooper()方法看能不能获取一个Looper对象,如果获取不到程序就直接蹦了。再从该Looper对象中获取我们需要的消息队列。

Looper到底是一个怎样的对象,有这怎样的身份,在Handler机制中扮演这怎样的角色?来看myLooper()方法:

1
2
3
public static @Nullable Looper myLooper() {
return sThreadLocal.get();
}

myLooper()方法会直接就从sThreadLocal对象中获取Looper,而sThreadLocal是一个ThreadLocal类对象,而ThreadLocal类说白了就是通过它存储的对象是线程私有的。

static final ThreadLocal sThreadLocal = new ThreadLocal();

调用get()方法直接从ThreadLocal中获取Looper,接下来就得看是何时set()将Loooper对象保存到ThreadLocal中去的。Looper.prepare()方法:

1
2
3
4
5
6
7
8
9
10
11
private static void prepare(boolean quitAllowed) {
if (sThreadLocal.get() != null) {
throw new RuntimeException("Only one Looper may be created per thread");
}
sThreadLocal.set(new Looper(quitAllowed));
}

private Looper(boolean quitAllowed) {
mQueue = new MessageQueue(quitAllowed);
mThread = Thread.currentThread();
}

从这段源码可以看出,Looper不仅是线程私有的还是唯一不可替换。Looper对象创建时会初始化MessageQueue()对象,正是我们需要的队列,那么prepare方法是什么时候调用的呢?

其实在ActivityThread的main方法中调用的,并初始化了sMainLooper对象。

1
2
3
4
5
6
7
public final class ActivityThread {
//......
public static void main(String[] args) {
Looper.prepareMainLooper();
}
//......
}
1
2
3
4
5
6
7
8
9
public static void prepareMainLooper() {
prepare(false);
synchronized (Looper.class) {
if (sMainLooper != null) {
throw new IllegalStateException("The main Looper has already been prepared.");
}
sMainLooper = myLooper();
}
}

到此我们算是明白消息会发送到哪儿去了,以及queue的身世起源。

2.2、Message的处理

首先MessageQueue封装有完整的添加(入队)和获取/删除(出队)方法,MessageQueeue.next()方法将链表当中表头第一个消息取出。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
Message next() {
//..........
for (;;) {
if (nextPollTimeoutMillis != 0) {
Binder.flushPendingCommands();
}

nativePollOnce(ptr, nextPollTimeoutMillis);

synchronized (this) {
final long now = SystemClock.uptimeMillis();
Message prevMsg = null;
Message msg = mMessages;
if (msg != null && msg.target == null) {
do {
prevMsg = msg;
msg = msg.next;
} while (msg != null && !msg.isAsynchronous());
}
if (msg != null) {
if (now < msg.when) {
nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
} else {
mBlocked = false;
if (prevMsg != null) {
prevMsg.next = msg.next;
} else {
mMessages = msg.next;
}
msg.next = null;
if (DEBUG) Log.v(TAG, "Returning message: " + msg);
msg.markInUse();
return msg;
}
} else {
nextPollTimeoutMillis = -1;
}

if (mQuitting) {
dispose();
return null;
}
//............
}
//..............
}
}

代码虽然比较多,我们从第三行和第39行开始说起。next()方法实际是一个死循环,会一直从当前队列中去取Message,即使当前队列没有消息可取,也不会跳出循环,会一直执行,直到能够从队列中取到消息next()方法才会执行结束。其次当Looper调用quit()方法,mQuitting变量为ture时会跳出死循环,next()方法返回null方法也会执行结束。上面提到在ActivityThread中的main()方法中会初始化Looper,其实在不久之后便会开始从队列中取消息。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public static void main(String[] args) {

//......
Looper.prepareMainLooper();

ActivityThread thread = new ActivityThread();
thread.attach(false);

if (sMainThreadHandler == null) {
sMainThreadHandler = thread.getHandler();
}

if (false) {
Looper.myLooper().setMessageLogging(new
LogPrinter(Log.DEBUG, "ActivityThread"));
}

Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
Looper.loop();

throw new RuntimeException("Main thread loop unexpectedly exited");
}

调用Looper.loop()方法就会开始遍历取消息。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
public static void loop() {
for (;;) {
Message msg = queue.next(); // might block
if (msg == null) {
return;
}

final Printer logging = me.mLogging;
if (logging != null) {
logging.println(">>>>> Dispatching to " + msg.target + " " +
msg.callback + ": " + msg.what);
}

final long slowDispatchThresholdMs = me.mSlowDispatchThresholdMs;

final long traceTag = me.mTraceTag;
if (traceTag != 0 && Trace.isTagEnabled(traceTag)) {
Trace.traceBegin(traceTag, msg.target.getTraceName(msg));
}
final long start = (slowDispatchThresholdMs == 0) ? 0 : SystemClock.uptimeMillis();
final long end;
try {
msg.target.dispatchMessage(msg);
end = (slowDispatchThresholdMs == 0) ? 0 : SystemClock.uptimeMillis();
} finally {
if (traceTag != 0) {
Trace.traceEnd(traceTag);
}
}
}

loop()方法中也是一个死循环,调用queue.nex()方法开始阻塞式取消息,只有手动让Looper停止,next()方法才会返回null。

取到消息后,调用dispatchMessage()方法把消息交由Handler处理。

msg.target.dispatchMessage(msg);

1
2
3
4
5
6
7
8
9
10
11
12
public void dispatchMessage(Message msg) {
if (msg.callback != null) { # post()中的run方法
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}

不仅可以给Handler设置回调接口,Message也行。默认情况下会回调handleMessage()方法。

本以为说得差不多了,其实还有一个关键的问题。我们是在主线程中执行的loop()方法,死循环为什么没有造成Activity阻塞卡死?查阅资料Android中为什么主线程不会因为Looper.loop()里的死循环卡死后得知next()方法中会执行一个重要方法。

nativePollOnce(ptr, nextPollTimeoutMillis);

大佬分析得很好,我就不多说了。提一点,我们发送的延时消息,会通过Message字段/变量when,将时长保存下来,延时也是通过这个方法做到的。

1
2
3
4
5
6
7
8
9
10
11
12
13
Message next() {

final long now = SystemClock.uptimeMillis();

if (msg != null) {
if (now < msg.when) {
// Next message is not ready. Set a timeout to wake up when it is ready.
nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
} else {
//......
}
}
}

总结,Handler发送消息会将消息保存到Looper维护的消息队列MessageQueue中去,而Looper会死循环一直从队列中取消息,取到消息后会交由Message绑定的Handler回调处理。

3、Handler内存泄漏

3.1、根本原因

当使用Handler的时候,我们需要警惕Handler的内存泄漏问题,其根本原因在于当这个Handler是非静态内部类的时候,它会持有一个对外部类的引用(比如Activity)。如果发送一条延时的Message,由于这个Message会长期存在于队列中,就会导致Handler长期持有对Activity的引用,从而引起视图和资源泄漏。

3.2、解决方法

  • 养成一个好的习惯,在onDestory方法中,及时取消队列中所有消息,并置空,示例如下:
1
2
3
4
if (null != mHandler) {
mHandler.removeCallbacksAndMessages(null);
}
mHandler = null;
  • 使用staticWeakReference配合,静态内部类不会持有对外部类的引用,所以定义一个静态的Handler,这样Acitivity就不会被泄漏了,同时让Handler持有一个对Activity的弱引用,这样就可以在Handler中调用Activity中的资源或者方法,示例如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
private TextView mTextView;
private Handler mHandler;

private final static int EVENT_UPDATE = 1;

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_handle);

mTextView = findViewById(R.id.text);

mHandler = new WeakHandler(this);
mHandler.sendEmptyMessageDelayed(EVENT_UPDATE, 20000);

}


private static class WeakHandler extends Handler {

WeakReference<HandlerActivity> weakReference;

public WeakHandler(HandlerActivity activity) {
weakReference = new WeakReference<HandlerActivity>(activity);
}

@Override
public void handleMessage(Message msg) {
HandlerActivity activity = weakReference.get();
switch (msg.what) {
case EVENT_UPDATE:
if (activity != null && activity.mTextView != null) {
activity.mTextView.setText("Min");
}
break;
default:
break;
}
}
}

4、参考: